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Abstract 

Synchronous solutions for Byzantine Fault Tolerance (BFT) can tolerate up to minority faults. In 
this work, we present Sync HotStuff, a surprisingly simple and intuitive synchronous BFT solution that 
achieves consensus with a latency of 2A in the steady state (where A is a synchronous message delay upper 
bound). In addition, Sync HotStuff ensures safety in a weaker synchronous model in which the synchrony 
assumption does not have to hold for all replicas all the time. Moreover, Sync HotStuff has responsiveness, 
i.e., it advances at network speed when less than one-quarter of the replicas are not responding, a small 
sacrifice in availability compared with optimal partially synchronous solutions. Borrowing from practical 
partially synchronous BFT solutions, Sync HotStuff has a two-phase leader-based structure, and has been 
fully prototyped under the standard synchronous message delay assumption. When tolerating a single 
fault, Sync HotStuff achieves a throughput of over 150 Kops/sec under typical network assumptions, 
which is comparable to the best known partially synchronous solutions. 


1 Introduction 

Advances in synchronous Byzantine Fault Tolerance (BFT) make synchrony a viable approach to the BFT 
Consensus problem that tolerate a minority corruption [1, 2]. The expected latency to commit in the 
synchronous setting was reduced from ~ 30 lock step rounds in Katz and Koo [3] to 10 rounds in Abraham 
et al. [4]. Recently, Hanke et al. [5] removed the need to work in a lock step fashion, thus simplifying 
the protocol as well as improving its efficiency. Improvements were also made along other dimensions to 
reduce assumptions on the synchrony bound and to improve latency. Chan et al. enhanced synchronous 
BFT to work in a weaker synchrony model, adhering to a wider set of real-life conditions [6]. Pass et al. [7] 
incorporated an optimistic network-speed commit track, thus reducing the latency gap and bringing it closer 
to protocols in the partial synchrony model (e.g., [8]). 

In this work, we introduce Sync HotStuff, a synchronous BFT state machine replication protocol that 
subsumes all the above advances as well as improves the latency with a surprisingly simple and intuitive 
solution (see Figure 1). In Sync HotStuff, in the standard synchrony model, a rotating leader broadcasts 
a proposal; the replicas echo it; and each replica commits after waiting for the maximum round-trip delay 
unless they hear by that time an equivocating proposal signed by the leader. It is easy to see that given a 
sufficient waiting period, due to the synchrony assumption, a replica would hear about a conflicting proposal. 
Sync HotStuff shows that a single round-trip delay waiting period suffices and the replicas will not arrive at 
conflicting commits. In addition to simplicity, Sync HotStuff significantly improves the latency to commit. 
More details on when a replica accepts a leader’s proposal and echoes are given in the body of the paper. 

Simple yet powerful, Sync HotStuff achieves the following desirable properties. First, as in most syn¬ 
chronous solutions, Sync HotStuff tolerates up to one-half Byzantine replicas. Second, like Hanke et al. [5], 
Sync HotStuff does not require lock step execution in the steady state. Third, Sync HotStuff is prototyped 
and shown to offer practical performance. It achieves a throughput comparable to partially synchronous 
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protocols. The latency to a decision is roughly a single maximum round-trip delay. Moreover, Sync HotStuff 
can accommodate the optimistically responsive mode of Pass et al. [7]. Finally, Sync HotStuff can handle 
and improve the latency for the weaker synchrony model of Chan et al. [6]. 

Before elaborating on the contributions and results, we first describe a distinction between latency for a 
single shot consensus and the latency for a state machine replication (SMR) system. Single shot consensus 
protocols optimize the expected latency for achieving consensus. However, practical approaches for SMR in 
the partial synchrony setting (e.g., PBFT [8], Paxos [9]) use a steady state leader that drives many decisions. 
Sync HotStuff embraces this approach and focuses on performance (throughput and latency) in the steady 
state under an honest leader. 

We proceed to elaborate on the contributions and key results in Sync HotStuff to remove performance 
barriers on synchronous BFT Consensus under weaker and more realistic assumptions. 

Practical throughput and near-optimal latency. Borrowing from Hanke et al. [5], replicas in Sync HotStuff 
do not run in lock steps in steady state. Consequently, replicas can start working on the next block upon 
receiving sufficient messages for the current block, allowing the progress to happen at the “network-speed” 
without waiting for the conservative synchrony delay bound. In fact, other than waiting for a short delay 
before committing, this behavior is exactly the same as partially synchronous protocols. Our experiments 
validate that Sync HotStuff achieves throughput comparable to partially synchronous protocols. In fact, since 
a synchronous solution tolerates a minority corruption (as against a one-third corruption with partial syn¬ 
chrony), it requires fewer replicas to be deployed to tolerate a given number of faults. In our experiments, 
we observe that for tolerating a fixed large number of faults, Sync HotStuff can even slightly outperform 
partially synchronous solutions, in terms of throughput. 

Sync HotStuff has a latency of 2A + 0(5) in steady state where A denotes the known bound assumed 
on maximal network transmission delay and 5 denotes the actual network delay, which can be much smaller 
than A. Assuming 6 <C A, the latency is within a factor of two of the optimal latency that can be obtained 
by synchronous protocols; a minor adaptation to the proof of Dwork et al. [2] shows that a A latency is 
necessary for any protocol tolerating more than one-third Byzantine faults. While only known as a folklore 
result, we prove this in the paper for completeness. The A latency lower bound should not be surprising 
because a protocol that commits faster than A, in a way, does not take advantage of synchrony and is thus 
subject to the one-third partial synchrony bound. In fact, we conjecture a stronger latency lower bound of 
2A. Our intuition is that replicas can be out-of-sync by A, so one A is needed for lagging replicas to catch 
up and another A is needed for messages to reach (the current lower bound proof only captures the latter 
A). Proving this stronger lower bound remains an intriguing open question. 

Moreover, though 0(5) latency is impossible to guarantee under more than one-third faults, it can be 
achieved optimistically. The Thunderella protocol [7] achieves 0(5) latency when the leader is honest and 
more than three-quarter of the replicas are responding. We show that our protocol can be adopted to 
incorporate this idea. 

Safety despite some sluggish honest replicas. Synchronous protocols proven secure under the standard 
synchrony assumption fail to provide safety if a single message is delayed. In practice, under real-life 
conditions, it is likely that over a long period of execution, we will observe some network aberrations. 
Recently, Chan et al. [6] proposed a “weak synchrony” model and a solution to address this concern. In 
short, the model allows the message delay bound A, at any point in time, to be violated for a set of honest 
replicas. We call these replicas sluggish. We call the remaining honest replicas prompt and their messages 
can reach each other within A time. To reflect reality and in fact, to be more conservative, the model 
considers sluggish replicas to be arbitrarily mobile , i.e., an adversary decides which replicas are sluggish at 
any time. Messages sent by or sent to a sluggish replica may take an arbitrarily long time until the replica 
is prompt again. Under such a model, Sync HotStuff ensures safety as long as the number of sluggish and 
Byzantine faults combined is less than one-half; in other words, at any time, a majority of replicas must be 
honest and prompt. This has been shown to be a necessary condition for tolerating sluggish replicas [10]. 
Compared to the 40A-65A latency of Chan et al. [6], Sync HotStuff achieves a latency of 2A + 9<j in steady 
state. Since “weak synchrony” has been used in the literature to describe other models (e.g., [11, 12, 13]), 
we will refer to this model as the mobile sluggish model in this paper. We call the synchrony mode without 
mobile sluggish faults standard synchrony. 

Organization. In the next subsection, we define state machine replication and the guarantees it provides. In 
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Let v be the current view number and replica L be the leader of the current view. The steady state protocol 
runs the following steps in iterations. 

1. Propose. The leader L broadcasts (propose, Bk,v,C(Bk~i))L where Bk = (bk,hk- 1 ), bk is a batch 
of new client requests, and Bk- 1 is the highest certified block known to L. 

2. Vote. Upon receiving the first valid height-fc block Bk from L or through a vote by some other 
replica, if it is extending a highest certified block, broadcast a vote in the form of (vote, Bk, v). Set 
commit-timer^ to 2A and start counting down. 

3. (Non-blocking) Commit. When commit-timer^, reaches 0, if Bk is the only height-fc block received, 
commit Bk and all its ancestors. 


Figure 1: The steady state protocol. 


Section 2, we describe Sync HotStuff in the standard synchrony model without sluggish faults. Section 3 aug¬ 
ments this protocol tolerate sluggish faults. Section 4 adds an optimistically responsive track to Sync HotStuff 
with sluggish faults. Section 5 presents the results based on our implementation and evaluation. Finally, 
Section 6 discusses works that are closely related. 

1.1 Definitions and Model 

State Machine Replication (SMR). A state machine replication protocol is used for building a fault- 
tolerant service to process client requests. The service consists of n replicas, up to / of which may be faulty. 
The service commits client requests into a linearizable log and produces a consistent view of the log akin 
to a single non-faulty server. More formally, a state machine replication service provides the following two 
guarantees 

- Safety: If a value is committed by any non-faulty replica at a log position, all non-faulty replicas 
eventually commit that value at the same position. 

- Liveness: Each client request is eventually committed by non-faulty replicas. 

We assume that the network consists of pairwise, authenticated communication channels between replicas. 
In addition, we assume digital signatures and a public-key infrastructure (PKI), and use ( x) p to denote a 
message x signed by replica p. For efficiency, it is customary to sign the hash digest of a message. We make 
the necessary synchrony assumptions in respective sections. 


2 Sync HotStuff under Standard Synchrony 

We first present Sync HotStuff in the standard synchrony model (without mobile sluggish faults). Here, the 
synchrony assumption states that a message sent at time t by any replica arrives at another replica by time 
t + A where A is a known maximum network delay. We use 5 to denote the actual message delay in the 
network. We show a protocol that tolerates minority Byzantine replicas, i.e., n = 2/ + 1. 

Sync HotStuff takes the Paxos/PBFT’s approach of having a stable leader in a steady state. The reign of 
a leader is called a view, numbered by integers. The leader of view v can simply be replica ( v mod n), i.e., 
leaders are decided in a round-robin order. The leader is expected to keep making progress by committing 
client requests at increasing heights. If replicas detect Byzantine behavior by the leader or lack of progress 
in a view, they blame the leader and engage in a view-change protocol to replace the leader. Figures 1 and 2 
describe the steady state and view-change protocols, respectively. 

Blocks and block format. As commonly done in SMR, client requests are batched into blocks. The 
protocol forms a chain of blocks. We refer to a block’s position in the chain as its height. A block Bk at 
height fc has the following format 

ddk (bk , hk— l) 
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Let L and L' be the leader of view v and v + 1, respectively. 

i Blame. If less than p blocks are received from L in (2 p + 1)A time in view v, broadcast (blame, v). 
If more than one block is proposed by L at any height ( L has equivocated), broadcast (blame, v) and 
the two equivocated blocks. 

ii Quit old view. Upon gathering / +1 (blame,!)) messages, broadcast them, and quits view v (abort 
all commit-timer(s) and stop voting in view v ). 

iii Status. Wait for A time and enter view v + 1. Upon entering view v + 1, send a highest certified 
block to L' and transition back to steady state. 


Figure 2: The view-change protocol. 


where b k denotes a proposed value at height k and hk-i := H{B k _i) is a hash digest of the predecessor block. 
The first block Bi = (& 1; _L) has no predecessor. Every subsequent block B k must specify a predecessor block 
i by including a hash of it. If B k is an ancestor of Bi ( l > k), we say Bi extends B k . We say a block is 
valid if (i) its predecessor is valid or _L, and (ii) its proposed value meets application-level validity conditions 
and is consistent with its chain of ancestors (e.g., does not double spend a transaction in one of its ancestor 
blocks). 

Certificates and certified blocks. A key ingredient of BFT solutions is a Quorum Certificate (certificate 
for short), a set of signatures on a block by a quorum of replicas. In Sync HotStuff, a quorum consists of 
/ + 1 replicas (out of 2/ +1). We use C(B k ) to denote a quorum of signatures on h k = H(B k ) from the same 
view and call it a certificate for B k . Certified blocks are ranked by heights. During the protocol execution, 
each replica keeps track of all signatures for all blocks and keeps updating the highest certified block to 
its knowledge. Looking ahead, the notion of highest certified blocks will be used to guard the safety of a 
commit. 

2.1 Steady State Protocol 

The steady state protocol runs in iterations. In each iteration, the leader L proposes a block by sending 
(propose, B k , v 1 C{B k ^i)) l where B k := {b kl h k - 1 ) is a new block and B k _ i is the highest certified block 
known to L (Step 1). If a leader has just entered the steady state after a view change, it should extend the 
highest certified block it learned during the view-change. If there are multiple such blocks, the leader can 
pick one arbitrarily. If the leader has been in the steady state, it should extend the previous block it has 
proposed. 

Each replica r, upon receiving a valid block B k from the leader, broadcasts a vote (vote, B k , v) r for it if 
it extends a highest certified block known to r (Step 2). Although the protocol assumes synchrony, replicas 
do not progress in lock steps. A replica r may first hear a block through another replica’s vote. A vote 
for a block can thus be considered a re-proposal of the block. In this case, if the block extends the highest 
certified block known to r, replica r also broadcasts a vote for B k . 

Once replica r votes for B k , it starts a timer called commit-timer^ (Step 3). B k is committed if r does 
not observe any equivocating blocks at height k within the next 2A time. Note that the commit timers do 
not affect the critical path of progress. A replica starts the next iteration “concurrently” without waiting for 
the previous height to be committed. In fact, a replica can potentially have many previous heights whose 
commit timers are still running. 

Why does absence of an equivocating block within 2A time suffice to ensure safety? Consider 
an honest replica r that votes for a block B k at time t, does not observe any equivocating block, and hence 
commits B k at time t + 2A. We will show that B k will be the only certified block at height k. For that, we 
need to show that (i) B k will be certified, and (ii) no conflicting height-fc block can be certified. 

r’s vote reaches all honest replicas before t + A. Recall that honest replicas vote for the first valid block 
received at each height in a view, and that they vote on blocks obtained through votes (i.e., votes serve 
as re-proposals). Thus, if any honest replica votes for a conflicting block B' kl it must do so before t + A; 
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otherwise, it would receive Bk from r first and vote for Bk . Therefore, if any honest replica votes for a 
conflicting block B' k , r would have known about B’ k before t + 2 A. This contradicts with the fact that r 
commits Bk- Hence, (ii) holds. On the other hand, if r does not receive an equivocating vote before t + 2A, 
r can be sure that all honest replicas have voted for B before t + A, and that it will receive all these votes, 
which form a certificate for Bk , before t + 2A. Hence, (i) holds. Note that (i) holds even if the leader did 
not propose Bk to all replicas. In summary, if a block Bk is committed by some honest replica, it will be 
the only certified block for that height. 

Remark. A commit by some honest replica at height k does not imply a commit by all honest replicas at 
that height. This is because a Byzantine leader can send an equivocating block to a subset of honest replicas 
before their commit timers expires, causing them to not commit. But the view-change protocol will ensure 
that all honest replicas eventually commit the same block, as will be explained in the next subsection. 

Certificate chaining and HotStuff. Note that blocks across heights are chained by certificates and 
committing a block commits all its predecessors. This is a key idea of the HotStuff framework [14]: having 
each voting step simultaneously play different roles at multiple heights greatly simplifies the protocol. In 
Sync HotStuff, the vote step of height k serves to also notify the certificate of height k — 1. 

2.2 View-change Protocol 

The view-change protocol ensures liveness. The leader can prevent progress through two mechanisms - 
stalling and equivocating. The two blame conditions, based on no progress and equivocation, defend against 
these two attacks, respectively. A leader is expected to propose a block every 2A time: one A for its proposal 
to reach other replicas and one A for other replicas’ votes to arrive. An extra A time is given to the leader 
in the beginning of the view to receive status. This forces a Byzantine leader to propose a block every 2A 
time to avoid being overthrown. If a leader equivocates by proposing conflicting blocks, the two equivocated 
blocks serve as a proof of Byzantine behavior and are sent together with the blame message. All honest 
replicas will blame the leader within A time. Note that equivocating blocks may be received directly from 
L or through a vote from other replicas. 

If a replica gathers / + 1 (blame, v) messages, it starts a view-change process by broadcasting the / + 1 
blame messages (Step ii). At this point, it quits view v, which involves stopping all commit timers and stop 
voting in view v. 

The replica then waits for A time to learn the highest certified block held among honest replicas, and 
then reports one such block to L' (Step iii). The A wait before sending status ensures that an honest replica 
learns all blocks committed by all honest replicas in previous views before sending status in a new view 
(formalized in Lemma 1). After that, a replica transitions back to steady state, and waits for the leader to 
propose a block that extends the block it reports in status. 

2.3 Safety and Liveness 

We say a block Bk is committed directly if an honest replica commits it by observing no equivocating block 
at height k within 2A after it votes. We say a block Bk is committed indirectly if it is a result of directly 
committing a block extending Bk- 

Lemma 1. If an honest replica directly commits a block Bi in a view, then (i) every honest replica votes for 
Bi in that view, and (ii) every honest replica receives C(Bi) before entering the next view. 

Proof. Suppose an honest replica r directly commits Bi at time t. h votes for Bi at time t — 2A. This vote 
reaches all honest replicas by time t — A. At this point, an honest replica r' will vote for Bi unless one 
of the two conditions below holds: (1) r' has already voted for B[ Bi before time t — A, or (2) r' has 
already received (and sent) n — f blame messages before time t — A. However, if either happens, r would have 
received either an equivocating vote or n — f blame messages before time t, which contradicts the hypothesis 
of r committing Bi at time t. Thus, at time t — A, all honest replicas are still in the view and they all vote 
for Bi. Moreover, all of them enter the next view at or after time t, and by then, they all receive C(Bi). □ 

Lemma 2. If an honest replica directly commits a block Bi, then there does not exist C(B[) where B[ ^ Bi. 
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Proof. Suppose an honest r replica directly commits a block Bi in view v. We will argue why a conflicting 
certificate does not exist prior to, in, or after view v. Firstly, if conflicting certificate exists prior to view v, 
then at least one of the votes comes from an honest replica. This vote would have reached r before view v 
and would have prevented r from committing Bi. Secondly, by Lemma 1, all honest replicas vote for Bi in 
view v. Thus, a conflicting height-? certificate cannot be formed in view v. Lastly, again by Lemma 1, every 
honest replica receives C(Bi) before entering view v + 1, and there was no conflicting height-? certificate up 
until then. From then on, the highest certified block of every honest replica is at least Bi , and no honest 
replica will vote for height-? blocks any more. Thus, no C{B[) where B[ 7 ^ Bi can come into existence in 
views greater than v. □ 

Theorem 3 (Safety). Honest replicas always commit the same block Bk for each height k. 

Proof. Suppose for contradiction that two distinct blocks Bk and B' k are committed at height k. Suppose 
B k is committed as a result of B[ being directly committed in view v and B k is committed as a result of 
B[, being directly committed in view v'. This implies Bi extends Bk and B' v extends B' k . Without loss 
of generality, assume ? < ?'. By Lemma 2, there exists no other certified block at height ?. If ? = ?', then 
B[, = Bp. if ? < ?', then B[, extends Bp In either case, B' k = Bk- □ 

Theorem 4 (Liveness), (i) A view change will not happen if the current leader is honest; (ii) A Byzantine 
leader must propose p blocks in (2 p+ 1)A time to avoid a view change; and (Hi) If k is the highest height at 
which some honest replica has committed a block in view v, then leaders in subsequent views must propose 
blocks at heights higher than k. 

Proof. For (i), note that an honest leader L is able to propose p blocks in (2 p+ 1)A time. Immediately after 
entering its view, L needs A time to gather status; after that, it can propose a block every 2A time: one A 
for its proposed block to reach all replicas and another A for other replicas’ votes to arrive. Thus, an honest 
leader has sufficient time and does not equivocate, so it will not be blamed by any other honest replica. On 
the other hand, if a Byzantine leader delays beyond the above allotted time it will be blamed by all honest 
replicas. 

For part (iii), observe that all honest receive C(Bk) due to Lemma 1. Hence, in status of subsequent 
views, they all report a certified block at height at least k. If the leader does not propose a block with a 
height higher than k within 3A, it will be blamed by all honest replicas. □ 

2.4 Efficiency Analysis 

Throughput. In steady state (Figure 1), the only step that uses the synchrony bound A is the commit step. 
But as we have mentioned, the commit step is not on the critical path (non-blocking). Thus, the choice of A, 
no matter how conservative, does not affect the protocol’s throughput in steady state. Thus, Sync HotStuff 
should have similar throughput as partially synchronous protocols. Our experiments in Section 5 confirm 
this. 

Latency. From an honest leader’s perspective, each block incurs a latency of 2A + 6 after being proposed. 
(Step 1 proceeds at the actual network delay <5.) But for SMR, it is more customary to calculate latency 
from a clients perspective, that is, the time difference between when a client sends a request and when it 
receives a response. If a clients request arrives between two leader proposals, it incurs an additional delay 
before being getting proposed. From a client’s perspective, it takes 6 to send its request to the replicas; 
on average, this request will arrive half way between two leader proposals, which are 26 time apart, so the 
average queue-up delay is S', it takes an additional 6 time for replicas to reply to the client. So the average 
client latency of Sync HotStuff is 2A + 4 6. Our experiments in Section 5 confirm this. 

For comparison, the best prior synchronous protocol in terms of latency is Hanke et al. [5]. Its average 
latency is 8 A + 9 6 from a leader’s perspective [15], and 9A + 11.56 from a client’s perspective, following a 
similar analysis. 
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2.5 Bound on Responsiveness 

Sync HotStuff commits with a 2A latency in the steady state when / < n/2. For completeness, in this 
section, we show a lower bound on the latency when / > n/3. The lower bound and the proof closely follow 
Dwork et al. [2]. For clarity, we present the bound in the Byzantine broadcast formulation. Recall that in 
Byzantine broadcast, a designated sender tries to broadcast a value to n parties. A solution needs to satisfy 
three requirements: 

(termination) all honest parties eventually commit, 

(agreement) all honest parties commit on the same value, and 

(validity) if the sender is honest, then all honest parties commit on the value it broadcasts. 
Theorem 5. There exists no Byzantine broadcast protocol that simultaneously satisfy the following: 

• termination, agreement and validity as defined above; 

• tolerates f > n/3 Byzantine faults; 

• terminates in less than A time if the designated sender is honest. 

Proof. Suppose such a protocol exists. Divide parties into three groups P, Q and R, each of size /. Parties 
in P and Q are honest and parties in R are Byzantine. Consider the following three scenarios. In Scenario 
A, parties in R remain silent and an honest designated sender sends 0. In this scenario, parties in P and Q 
commit 0 in less than A time. In Scenario B, parties in R remain silent and an honest designated sender 
sends 1. In this scenario, parties in P and Q commit 1 in less than A time. In Scenario C, the designated 
sender is Byzantine and sends 0 to P and 1 to Q; parties in R behave like Q in Scenario A to P, and behave 
like P in scenario B to Q. Messages between P and Q take A to reach. This scenario is indistinguishable 
from Scenario A to P and indistinguishable from Scenario B to Q. Thus, P commits 0 and Q commits 1 in 
less than A time, violating agreement. □ 


3 Sync HotStuff with Mobile Sluggish Faults 

The standard synchrony model used in the previous section requires that every message sent by an honest 
replica arrives at every other honest replica within A time. In practice, such an assumption may not hold all 
the time due to potential unforeseen aberrations in the network at either the sender or the receiver, causing 
some messages to be delayed. Under such aberrations, a protocol proved secure under the standard synchrony 
assumption may lose safety. For our protocol specifically, if a replica that holds an equivocating proposal 
runs into a network glitch, then another honest replica may not receive it in time and may incorrectly commit 
another block. A potential way to “fix” this is to account for the sender (or receiver) of the delayed message 
as Byzantine and thus tolerate fewer actual Byzantine faults. Unfortunately, over an execution period of 
a few years, every replica is bound to observe such an aberration and this “fix” will result in a dishonest 
majority of replicas, thus breaking safety eventually. 

3.1 The Mobile Sluggish Model 

Chan et al. [6] consider a weaker model that allows some replicas to be sluggish, i.e., allows delays for 
messages sent/received by sluggish replicas in the network. On the other hand, messages sent by prompt 
replicas will respect the synchrony bound. More specifically, if a replica rq is prompt at time t\, then any 
message sent by r\ at time < t-\ will arrive at a replica ri prompt at time t -2 if t 2 > t\ + A. Moreover, the 
set of sluggish replicas can arbitrarily change at every instant of time. Hence, we call this model the mobile 
sluggish fault model. We denote the number of sluggish replicas by d, the number of Byzantine replicas by 
b and the total number of faults by /. Thus, f = d + b. 

We note that the mobile sluggish model expects that a message sent by a sluggish replica would respect the 
synchrony bound as soon as it becomes prompt. In practice, this model captures temporary loss in network 
connectivity causing message delays. The replica can resend messages as soon as network connectivity is 
restored. A similar argument holds for receiving messages. However, it is not a good model for capturing 
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a replica going offline for too long since this would require the replica to either buffer a huge amount of 
messages to be resent or to resend each message many times, both of which are impractical. 

3.2 Protocol 


Let v be the current view number and replica L be the leader of the current view. The steady state protocol 
runs the following steps in iterations. 

1 . Propose. The leader L broadcasts (propose, Bk, v,C(Bk-i)) l where Bk = {bk,hk~ 1 ), bk is a batch 
of new client requests, and Bk- 1 is the highest certified block known to L. 

2. Vote. Upon receiving the first valid height-fc block Bk from L or through a vote by some other 
replica, if it is extending a highest certified block, broadcast a vote in the form of (vote, Bk, v). Set 

pre-cornmit-timer fc _2 to 2A and start counting down. 

3. (Non-blocking) Pre-commit. When pre-commit-timer,, reaches 0, if Bk is the only height-fc block 
received, pre-commit Bk and broadcast (commit, Bk, v). 

4. (Non-blocking) Commit. On receiving (commit, Bk, v) from /+ 1 distinct replicas with the same 
v, commit Bk and all its ancestors. 


Figure 3: The steady state protocol. 

Under weak synchrony, Guo et al. [10] show that no protocol can tolerate a total number of faults (sluggish 
plus Byzantine replicas) greater than nj 2. The intuition is that a majority set consisting of Byzantine and 
sluggish replicas might reach a commit decision without interacting with the rest of the world and might 
cause conflicting commits. Thus, we assume > n/2 replicas are honest and prompt at any time. Moreover, 
the protocol guarantees liveness when the same set of > n/2 honest replicas are prompt for a “sufficiently 
long” period of time, i.e., there can be sluggish replicas but they are not mobile. The duration is directly 
related to the time required to commit a block in the protocol. 

Protocol intuition. In the synchronous protocol described in Section 2, the 2A period immediately after a 
vote was used to ensure the following. If no equivocation was observed, i.e., if the 2A period was undisturbed, 
then a vote for a block Bk by a replica r ensured that both, the replica r and all other replicas receive C(Bk) 
within 2A. This is because no other honest replica would have voted for an equivocating block and thus all 
honest replicas would vote for Bk . Thus, no other certificate would have been formed or committed. On the 
other hand, the presence of an equivocation implies the potential existence of another certificate, preventing 
replica r from committing. 

In the presence of sluggish replicas, unfortunately, none of the above arguments hold. A sluggish replica, 
even in the absence of an equivocation, may not receive a certificate in the 2A period. Similarly, other 
replicas may not receive its votes and consequently certificates. Finally, if an equivocation exists, the replica 
may not receive it in time. 

Intuitively, these argument fail in the mobile sluggish model because we rely on a single replica’s vote 
to ensure safety but this replica can now be sluggish. The natural fix is to rely on > d + 1 honest replicas’ 
votes. Then, at least one of the votes would have been sent by a prompt replica and it would ensure safety. 
Unfortunately, if a replica receives d + 1 votes, it cannot determine if the votes are received from d+1 prompt 
replicas or a combination of Byzantine and sluggish replicas. Thus, we rely on a certificate C(Bk) which is 
bound to contain one vote from an honest and prompt replica which is capable of sending it to other prompt 
replicas. 

The above intuition suffices for a certificate to be formed at replica r; it knows it can obtain a certificate 
because it has already received the certificate. However, it doesn’t guarantee a certificate at other honest 
replicas. This can cause safety violations if at the end of the view, sufficient honest replicas do not have a 
certificate and some other value is proposed and committed in subsequent views. We solve this by using the 




same intuition again — if a replica has received a C(C (£/&)), then C(Bk ) must have been voted by one of the 
prompt replicas. This ensures a certificate at all prompt replicas. 

Finally, observe that even if a replica observes an undisturbed- 2 A period after receiving C(C(Bk )), then 
the commit is not guaranteed. This is because the replica could be sluggish and may not have received an 
equivocating block. However, if the replica hears from a majority honest replicas about an undisturbed-2A 
period, then an equivocation could not have missed all of them and thus the replica can commit the block. 
We call the prior state a pre-commit and the latter state a commit. 

Protocol. Interestingly, despite a weaker model than the standard synchrony assumption, based on the 
intuition presented above, the protocol is only marginally different from the one presented in Figures 1 and 
2. For clarity we present the entire steady state protocol and gray out the repetition in Figure 3. The view 
change protocol remains unchanged. 

Now, since we require a C(C(Bk )) before waiting for the 2 A period, we start a pre-commit timer for Bk~ 2 
on receiving B^. When the pre-commit timer expires, the replica broadcasts a commit request (commit, B^ , v) 
to all replicas. Upon receiving n — f commit requests, the replica commits since at least one of the requests 
is from a prompt replica. 

3.3 Safety and Liveness 

We say a block Bk is committed directly if it is committed due to / + 1 pre-commits. We say a block B is 
committed indirectly if it is a result of directly committing a block extending B^. 

Lemma 6 . If an honest replica directly commits a block Bi in view v, then f + 1 honest replicas (i) vote for 
Bi in that view, and (ii) receive C(B[) before entering the next view. 

Proof. If an honest replica directly commits Bi in view v, then d + 1 honest replicas pre-commit Bi in view 
v. Denote the set of these d +1 replicas by R. Let the earliest pre-commit among R be performed by replica 
r at time t. Thus, replica r must have received B ; +2 at time t — 2A. This implies that / + 1 replicas have 
voted for Bi + 1 before time t — 2A. Since / + 1 replicas are honest and prompt at time t — 2A, at least one of 
these replicas, say replica h, intersects the quorum of replicas that voted for Bi + \. Denote the set of honest 
and prompt replicas at time t — A by R'. Since h is honest and prompt at t — 2A, its vote for B 1 + 1 , which 
contains C(Bi), reaches all replicas in R' by time t — A. 

We will now prove that the set R' is the required set that satisfies the two conditions in the lemma. The 
only scenario in which this is not true is if one of the replicas in R !, say replica r' has voted for a conflicting 
block or has quit view v before time t — A. However, because r' is honest and prompt at time t — A, before 
time t, its broadcast of conflicting vote or blame certificate will reach all honest replicas that are prompt 
at time t. At least one replica in the pre-committing set R would be prompt and would have received this 
message by time t. It would have prevented the pre-commit of Bi at that replica, a contradiction. □ 

Remark. Note that the above lemma states that R' receives C(-Bfc) before quitting view v. Thus, the A 
wait during view change is not needed for the protocol with sluggish faults. 

Lemma 7. If an honest replicas directly commits a block Bi in a view, then there does not exist C{B[) where 

Bi ^ B[. 

Proof. If an honest replica directly commits Bi in view v, then a set R of d + 1 honest replicas pre-commit 
Bi in view v. We will argue why a conflicting certificate does not exist prior to, in, or after view v. Firstly, 
if conflicting certificate exists prior to view v, at least one replica in R would not received a conflicting vote 
before view v, and would not have pre-committed Bi. Secondly, by Lemma 6, / + 1 honest replicas vote for 
Bi in view v. Thus, a conflicting height-/ certificate cannot be formed in view v. Lastly, again by Lemma 6, 
f + 1 honest replica receive C{Bi) before entering view v +1, and there was no conflicting height-/ certificate 
up until then. From then on, the highest certified block of these / + 1 honest replicas is at least Bi, and 
they will not vote for height-/ blocks any more. Thus, no C(B[) where B[ ^ Bi can come into existence in 
views greater than v. □ 
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Safety. The safety proof remains identical to that of Theorem 3 except that Lemma 7 is invoked in lieu of 
Lemma 2. 

Liveness. In the mobile sluggish model, liveness is guaranteed only during periods in which all honest 
replicas stay prompt. In that case, the same arguments in Theorem 4 hold. We do not repeat the proof. 

3.4 Efficiency 

In the mobile sluggish model, each pre-commit timer starts two proposals later, adding 45 latency. The 
commit messages add another round of communication and 5 latency. So the total latency becomes 2A + 
45 + 55 = 2A + 95. 

4 Sync HotStuff with Optimistic Responsiveness 

In this section, we incorporate the Thunderella [7] optimistic responsive mode into Sync HotStuff. In Sec¬ 
tion 2, a certificate/quorum required only / + 1 votes. Thus, a vote from a single honest replica can result 
in a certificate if all f Byzantine replicas vote on the same block. Therefore, before committing a block, a 
replica needs to wait long enough to hear all honest replicas’ votes and make sure none of them voted for a 
conflicting block. The commit latency thus inherently depends on the maximum network delay A. In con¬ 
trast, partially synchronous protocols rule out the existence of a conflicting certificate with larger quorums. 
For instance, PBFT requires > 2n/3 votes (in two phases) and tolerates f < n/3 Byzantine replicas. A 
simple quorum intersection argument shows that two conflicting blocks cannot both receive > 2n/3 votes. 
Thus, partially synchronous protocols commit as soon as these quorums of votes are obtained, so the latency 
does not depend on A. 

Pass and Shi [7] use the term responsive to capture the above latency distinction. A protocol is said to 
be responsive if the latency only depends on the actual network 5 but not the maximum network delay A. A 
protocol is said to be optimistically responsive if it achieves responsiveness when some additional constraints 
are met. 

Since Sync HotStuff aims to tolerate up to minority corruption, similar to Thunderella [7], to achieve 
responsiveness we will use a quorum size of > 3n/4. This will give Sync HotStuff a responsive mode that 
is optimistically responsive when messages from > 3n/4 replicas reach within time 5. This happens if the 
actual number of faults is less than n/4. Put differently, if more than n/4 replicas are faulty, they can 
prevent responsiveness but they cannot cause a safety violation. In that case there is no responsive progress, 
we fall back to the synchronous mode in Section 3. 

4.1 Protocol 

Since the responsive mode requires a larger quorum, we introduce the notion of a strong certificate. A block 
B is said to have a strong certificate if it has > 3n/4 votes. It is denoted by C qj (B ). In the responsive mode, 
honest replicas only vote for blocks that extend predecessors with strong certificates, namely, in the form of 
ddk = ifikiCqffihk— l)). 

Figure 4 describes the augmented protocol with the responsive mode, augmented from the protocol in 
Section 3. Below, we highlight the modifications and how to switch between the modes. Each view starts 
in the synchronous mode. If the leader recognizes that > 3n/4 replicas are voting, it signals a switch to 
the responsive mode by including a strong certificate. Once a replica votes for a block containing a strong 
certificate, it switches to the responsive mode. Once in the responsive mode, a replica will only vote for 
blocks containing strong certificates for the rest of the view. But crucially, the responsive commit rule (based 
on two strong certificates) does not immediately kick in. The replicas need to commit one more block using 
the synchronous commit rule after switching to the responsive mode. This essentially “commits the switch” 
using the regular synchronous commit rule, i.e., it ensures that most replicas have switched to the responsive 
mode. 

Whenever the responsive mode fails due to an equivocating leader or lack of progress, replicas engage in 
a view change (Figure 5) to move to the next view and start in its synchronous mode. Guarding the safety 


10 



Let v be the current view number and replica L be the leader of the current view. The steady state protocol 
runs the following steps in iterations. 

1 . Propose. The leader L broadcasts (propose, Bk, v,C(Bk-i)) l where B j. = {bk,hk~ 1 ), bk is a batch 
of new client requests, and Bk- 1 is the highest certified block known to L. 

2. Vote. Upon receiving the first valid height-fc block Bk from L or through a vote by some other 
replica, if it is extending a highest certified block, broadcast a vote in the form of (vote, Bk, v). If 
Bk contains a strong certificate for its predecessor, switches to the responsive mode and only vote for 
blocks with strong certificates for the rest of this view. 

3. (Non-blocking) Pre-commit. If at least one block has been committed in the responsive mode of 
this view, pre-commit Bk -1 and broadcast (commit, Bk- 2 , v) right away. Else, set pre-commit-timer fe _2 
to 2A and start counting down. When pre-commit-timer fc _ 2 reaches 0, if Bk -2 is the only height-fc 
block received, pre-commit Bk- 2 and broadcast (commit, Bk- 2 , v). 

4. (Non-blocking) Commit. On receiving (commit, Bk, v) from / + 1 distinct replicas with the same 
v, commit Bk and all its ancestors. 


Figure 4: The steady state protocol augmented with the responsive mode. 


Let L and L' be the leader of view v and v + 1, respectively. 

i Blame. If less than p blocks are received from L in (2 p+ 1)A time in view v, broadcast (blame, v). 
If more than one block is proposed by L at any height ( L has equivocated), broadcast (blame, v) and 
the two equivocated blocks. 

ii Quit old view. Upon gathering / + 1 (blame, v) messages, broadcast them along with (blame2,n), 
and quits view v (abort all pre-commit-timer(s) and stop voting in view v). 

iii Status. Upon gathering / + 1 (blame2,w) messages, Wait for 2A time and enter view v + 1. Upon 
entering view v + 1, send a highest certified block to L' and transition back to steady state. 


Figure 5: The view-change protocol to support the responsive mode. 


of responsive commits turns out to be non-trivial. We provide an intuition of the concern and our approach 
to solving it. This is discussed formally in Lemmas 8 and 9. 

In the protocol without responsiveness, a commit implied that a certificate was broadcast by some prompt 
replica 2A time earlier. This ensured that a certificate was obtained at a majority of honest replicas at or 
before they quit the view. Since we do not wait for 2A time in the responsive mode, this does not hold any 
more. First, some of the sluggish replicas (sluggish even before the responsive honest commit) can quit the 
old view and enter the new view without informing a majority of honest replicas. In the new view, they 
may vote for an unsafe block. By itself, this does not create a safety violation since d + b < f. However, in 
combination with the sluggish mobility that is introduced right after a prompt responsive honest commit, 
another set of d replicas may not learn a certificate before switching to the next view leading to a safety 
violation. Our solution separates the process of quitting the old view and entering the new view with a 2A 
delay (Steps ii and iii). The delay is introduced at a replica after learning that a majority of replicas have 
quit the view giving it sufficient time for the certificates to be sent across to a majority of prompt replicas 
before they enter and subsequently vote in the next view (Step iii). These changes will be utilized in the 
proof of Lemma 8 . 
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4.2 Safety with Optimistic Responsiveness 

We now amend the proofs for safety to account for the addition of the responsive mode. Lemma 6 and 7 
apply to directly committed blocks in the synchronous mode. We provide two similar lemmas for directly 
committed blocks in the responsive mode. 

Lemma 8 . If an honest replica directly commits a block Bi in a view, then f + 1 honest replicas receive 
C(B[) before entering the next view. 

The proof is very similar to that of Lemma 6 . The only difference is that the 2A before pre-commit now 
happens during view change. 

Proof. If an honest replica directly commits Bi in view v, then d + 1 honest replicas pre-commit Bi in view 
v. Denote the set of these d+ 1 replicas by R. Let the earliest pre-commit among R be performed by replica 
r at time t. At least d+ 1 honest replicas voted for Bi +1 before time t. At least one of them is honest prompt 
at time t. Its vote B/+i reaches the set of honest replicas that are prompt time t + A. Denote this set by 
R'. R' has size at least / + 1 and satisfies the lemma. The only scenario in which this is not true is if one of 
the replicas in R' , say replica r' has entered view v + 1 before time t + A. In that case, due to the 2A wait 
during view change, r' has received / + 1 blame2 messages before time t — A. Thus, / + 1 replicas have sent 
blame2 and quit view v before time t — A. One of them is honest and prompt at time t— A. Thus, at least 
one replica in the pre-committing set R would be prompt and would have received this blame2 message by 
time t. It would have prevented the pre-commit of Bi at that replica, a contradiction. □ 

Lemma 9. If an honest replica directly commits a block Bi in the responsive mode, then there does not exist 
C(B[) where B[ 7 ^ Bi. 

Proof. If an honest replica directly commits B[ in the responsive mode of view v, it implies two things: 
(1) that replica has performed a synchronous commit on an ancestor of Bi , say B k , that contains a strong 
certificate to its predecessor, ( 2 ) a set R of d + 1 honest replicas pre-commit Bi in the responsive mode of 
view v, We will argue why a conflicting certificate does not exist prior to, in, or after view v. Firstly, due to 
Lemma 7, a synchronous commit of B k rules out any conflicting certificate for B' k 7 ^ B k in prior views. So 
there will not be any conflicting certificate for B[ 7 ^ Bi in prior views. Secondly, the commit if B k implies 
that at most d honest replicas are left behind in the synchronous mode, not enough to produce a conflicting 
certificate. Meanwhile, a strong certificate for B[ 7 ^ Bi requires at least (3n/4 + 1) + (3n/4 + 1) — n = 
n/2 + 1 = / + 1 replicas to double-vote at height l, which cannot happen. Lastly, by Lemma 8 , / + 1 honest 
replica receive C(Bi) before entering view v + 1, and there was no conflicting heiglit-l certificate up until 
then. From then on, the highest certified block of these / + 1 honest replicas is at least Bi , and they will not 
vote for height-1 blocks any more. Thus, no C(yB[) where B[ 7 ^ Bi can come into existence in views greater 
than v. □ 

Safety. The safety proof remains identical to that of Theorem 3 except that Lemma 7 and Lemma 9 both 
need to be invoked. 


5 Evaluation 

We implement the Sync HotStuff protocol under the standard synchrony model and evaluate the throughput 
and latency under different conditions. The implementation is an adaptation of HotStuff [14], We modify the 
HotStuff code to primarily replace the core protocol logic while keeping the rest part, such as event-driven 
protocol skeleton and network library unchanged. 

In our implementation, replicas reach consensus on a sequence of blocks. Each block contains a batch of 
commands sent by clients. A command consist of a unique identifier and an associated payload. We refer to 
the maximum number of commands in a block as the batch size. A conceptual representation of a block is 
shown in Figure 6. 

In this section, we first evaluate the system under different choices of batch size or payload, as we 
vary the load by all clients. We then evaluate the impact of A on throughput and latency and show it 
is insignificant. Finally, we compare Sync HotStuff with HotStuff, a partially synchronous protocol as our 
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Figure 6 : Structure of a block in the implementation. 
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(a) Varying batch sizes. (b) Varying payload. 

Figure 7: Throughput vs. latency of Sync HotStuff at varying batch sizes and payloads at A = 50 ms and / 
= 1 . 


baseline, for different system sizes. This demonstrates the scalability of Sync HotStuff under different choices 
of tolerated network faults, client’s payload size, and network latency. We pick HotStuff as our baseline 
because (i) Sync HotStuff shares the same code base as HotStuff enabling a fair comparison, and (ii) HotStuff 
achieves comparable (sometimes even better) performance to the state-of-the-art partially synchronous BFT 
implementation [14]. 

5.1 Setup 

All our experiments were conducted over Amazon EC2 where each replica was executed on a c5.4xlarge 
virtual machine. Each VM had 16 vCPUs supported by Intel Xeon Platinum 8000 processors. All cores 
sustained a Turbo CPU clock speed up to 3.4GHz. The maximum TCP bandwidth measured by iperf is 
around 9.6Gbps, i.e., 1.2 Gigabytes per second. We did not throttle the bandwidth in any run. The network 
latency between two machines is less than 1 ms. We used secp256kl for all digital signatures in votes and 
certificates. All throughput and latency results were measured from clients which are separate processes run¬ 
ning on machines different from those for replicas. Each client generates a number of outstanding commands 
and broadcasts them to every replica. Replicas only use the unique identifier (e.g. hash) of a command to 
represent it in proposals and votes. To execute the commands for the replicated state machine, a replica 
either has the command content received from the client’s initial broadcast, or fetches it from the leader if 
the client crashes before it finishes the broadcast. We use four machines, each running four client processes, 
to inject commands in to the system. Each client process can maintain a configurable number of outstanding 
commands at any time. We ensure that the performance of replicas will not be limited by the clients. 
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(a) A vs. throughput. (b) A vs. latency. 

Figure 8: Performance of Sync HotStuff at varying A and / at batch size = 400 and 0/0 payload. 

5.2 Base Performance 

We first evaluate the base performance of Sync HotStuff to tolerate / = 1 fault for a synchrony bound of 
A = 50 ms. We measure the observed throughput (in number of commands conrmitted/sec or ops/sec) and 
end-to-end latency for clients (in ms). We conduct two experiments. The first one fixes the payload and 
varies batch size (Figure 7a) while the other fixes a batch size and varies the payload size (Figure 7b). 

In Figure 7a, each command has a zero-byte payload to demonstrate the overhead induced solely by 
consensus and state machine replication. We consider three different batch sizes, 100, 400 and 800, repre¬ 
sented by the three lines in the throughput-latency graph. In the graph, each point represents the measured 
throughput and latency for one run with a given “load” by the clients. More specifically, a client process 
maintains a fixed number of outstanding commands at any moment. When an outstanding command is 
committed, a new command is immediately issued to keep up with the specified number. We vary the size 
of the outstanding command pool to simulate different loads. The points at the lower left represent the 
state when the system is not saturated by client commands. As the load increases, the throughput initially 
increases without incurring a loss in latency. Finally, after the load saturates the bandwidth, the throughput 
remains unchanged (or slightly degrades) when clients inject more commands, while the latency goes up. 
The latency increases because the commands stay in the command pool longer before they are proposed 
in a block for consensus. For a batch size of 400, we observe that the throughput is saturated at around 
150Kops/sec. There is no further throughput gain when batch size increases from 400 to 800. So in all of 
our following experiments, we fix our batch size to 400. 

We also test how payload size of a command affects performance. Figure 7b shows the performance with 
three client request/reply payload sizes (in bytes) 0/0, 128/128 and 1024/1024, denoted by “pO”, “pl28”, and 
“pl024”. In addition to the actual payload, each command also contains an 8 byte counter to differentiate 
the commands. For example, the actual command size for 0/0 is 8 bytes. 




Figure 9: Performance as function of faults and payload size at A = 50 ms and batch size = 400. 
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5.3 The Impact of A on Performance. 

In the steady state, Sync HotStuff allows replicas to respond as soon as messages arrive. Given a sufficiently 
high load from the clients, the system is able to proceed to the next block quickly and saturate the network 
bandwidth. However, for every block it waits for a 2A decision period. Figures 8 a and 8 b study the effect of 
varying A on throughput and latency. Each line represents a choice of /, denoted by “ 1 ”, “8”, “32”, “64”. 
As expected, we observe that the saturated throughput and latency remains unaffected by different choices of 
A. We do note that the latency remains unaffected only when the A bound is conservative. This is because, 
in this case, the time for certifying a block (the 0(5) terms in our theoretical analysis) is overshadowed by 
the 2A wait. When tolerating a larger number of faults and when lower bandwidths are used, A should be 
set appropriately to reflect this to ensure safety. 

5.4 Scalability and Comparison with Partial Synchrony 

We perform an experiment to understand how Sync HotStuff scales as the number of replicas increases and 
how it compares with a partially synchronous protocol. In our baseline, clients issue zero-byte payload 
commands and saturate the system, without overloading the replicas. We then vary the choice of /. Each 
experiment is repeated five times with the same setup to average out fluctuations. A data point shows the 
average value, capped by error bars indicating the standard deviation. Since synchronous protocols tolerate 
one-half faults as against one-third in case of partial synchrony, for the same /, the actual number of replicas 
is 2/ + 1 for Sync HotStuff, whereas it is 3/ + 1 for HotStuff. We would also like to point out that such 
comparison is not entirely “fair” since a partially synchronous protocol does not assume a synchrony bound. 
Nevertheless, from a practical point of view, it is still helpful to evaluate the performance of a synchronous 
protocol compared to a partially synchronous protocol like HotStuff. 

Figures 9a and 9b show the throughput and latency for two different payload configurations, 0/0 and 
1024/1024. For both configurations, at fewer faults, the throughput of Sync HotStuff is slightly worse than 
HotStuff and at more faults, the throughput of Sync HotStuff is better than HotStuff. This holds because in 
both cases the system is bottlenecked by a leader communicating with all other replicas. Since Sync HotStuff 
requires fewer replicas to tolerate the same number of faults, its performance scales better than HotStuff as 
the number of faults increase. For example, for / = 64, Sync HotStuff only requires 129 replicas, whereas 
HotStuff needs 193. This disadvantage in size penalizes the performance of HotStuff for the same /-tolerance. 
In general, for all runs, the throughput of Sync HotStuff is comparable to that of HotStuff. 

6 Related Work 

Several decades of research on the Byzantine agreement problem [1] brought a myriad of solutions. Dolev 
and Strong gave a deterministic Byzantine broadcast protocol for / < n — 1 [16]. Their protocol achieves 
/ + 1 round complexity and 0(n 2 f) communication complexity. The / + 1 round complexity matches the 
lower bound for deterministic protocols [17, 16]. To further improve round complexity, randomized protocols 
have been introduced [18, 19, 20, 21, 3, 4]. We review the most recent and closely related works below. 

Dfinity. The Dfinity Consensus protocol described in [5] is a replication protocol in the synchrony model 
that tolerates f < n/2 Byzantine faults. It makes a key observation that a synchronous replication protocol 
can start processing the next client request without waiting for the previous one to commit. While a standard 
practice in partially synchronous protocols, this was not obvious for synchronous protocols. However, as 
observed in a recent technical report [15], the presentation in [5] allowed unbounded message complexity 
due to an unnecessary requirement that honest replicas vote for all leader proposals, including conflicting 
ones. Latency-wise, it has an expected latency of 9A + 0(5) after taking into account the latency due to 
random leaders and the delay in proposing a block after it has been received from a client. Sync HotStuff 
adopts the non-lock-step approach of Dfinity while reducing the expected latency to 2A + 0(5) and making 
the expected message complexity quadratic. 

Thunderella. The idea of optimistic responsiveness (under one-quarter faults) was introduced in Thun- 
derella [7]. When more than 3n/4 replicas are correct, Thunderella can commit a decision in one phase. 
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However, the decision cannot be conveyed to external clients, hence it does not support SMR in the tradi¬ 
tional sense. Thunderella uses the synchronous mode to monitor the progress of the responsive mode and, if 
it does not make progress quickly, falls back to the synchronous mode. The fallback mechanism is presented 
in a black-box fashion but it is unclear how it works in a non-Nakamoto-style protocol. In comparison, 
Sync HotStuff uses two-phase commit in the responsive path, and hence provides safety for SMR. Moreover, 
we take the conventional approach of having replicas monitor the progress of the responsive mode, and using 
the view change protocol to perform the fallback. 

PiLi. A recent work PiLi [6] presented the mobile sluggish fault model (called weak synchronous model in 
that work) and also presented the first solution to it. This model better reflects reality compared to the 
standard synchrony assumption and we borrow this fault model. PiLi presents a lock step solution where 
each “epoch” lasts 5A time and it commits the first 5 blocks after 13 consecutive epochs if certain conditions 
are met. Thus, PiLi requires a latency of at least 40A-65A (65A for the earliest block and 40A for the last 
committed block). In comparison, our solution requires 2A + 98 latency where 5 denotes the actual network 
delay. 

XFT. A different type of protocol with optimistic responsiveness is XFT [22]. XFT guarantees responsiveness 
when a group of /+1 honest replicas is determined. Thus, when the actual number of faults is t, it may take 
(/+].) / (/+i) y i ew changes for an honest group of / + 1 to emerge; after that time, the protocol is responsive. 
Such a solution is practical when t is a small constant but for t = O(n), it requires an exponential number 
of view changes to find an honest group. In comparison, Sync HotStuff is responsive under t < n/A faults 
after at most t view changes. 

7 Conclusion 

In this work, we introduce Sync HotStuff, a simple and practical synchronous BFT SMR protocol. Sync HotStuff 
does not require lock step execution, tolerates mobile sluggish faults, and offers practical performance. As 
we mentioned, the mobile sluggish fault model captures short network glitches but is not ideal for replicas 
going offline for too long. It remains interesting future work to come up an even weaker and more realistic 
synchronous model as well as practical solutions in that model that still tolerate up to minority faults. 
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